IAM Access Analyzer によるポリシーの生成が失敗し CloudTrail ログファイルの処理数が上限を超えたエラーが表示された時どうする
CloudTrail log files processed per policy generation limit exceeded. Please fix before trying again.
コンバンハ、エラーメッセージを見かけたら愚直にそのままコピペして検索するおじさんこと、千葉（幸）です。
IAM Access Analyzer によるポリシー生成の失敗時に冒頭のエラーが表示されたのですが、愚直にそのままコピペして検索してもこれといった情報がヒットしませんでした。なので、自分で書くことにしました。
エラーメッセージを愚直に検索してこのエントリに辿り着いた方はまず答えを知りたいかと思いますので、先にまとめを書きます。
まとめ
- ポリシーの生成時に処理できる CloudTrail ログファイルの上限は 100,000 であり、冒頭のエラーはその上限を超えていることを表すメッセージである
- 回避するためにポリシーの生成時に指定するリージョンを取捨選択しよう
- 普段利用していないリージョンでもログファイルは意外と生成されている
aws s3 lsで--summarize --recursive --human-readableオプションを指定してログファイル数を確認できる
- 分析対象の期間を短くするのも有効
IAM Access Analyzer によるポリシー生成とは
このエントリを見るモチベーションがある方には改めての詳細説明は不要かと思います。
2021 年 4 月に発表されたもので、 特定の IAM ユーザーや IAM ロールに対して CloudTrail に記録された過去のアクティビティを基にポリシーの雛形を生成してくれる機能です。
分析時に CloudTrail ログを参照している、というのが一つの肝です。
機能自体の詳細は以下をご参照ください。
エラーはどんな時にでる
冒頭のエラーに見舞われた方は、以下の条件でポリシーの生成を行ったのではないでしょうか。
- 分析期間として 90 日間もしくはそれに準じる長期間を指定した
- 対象のリージョンとして全てを指定した
もちろん上記に当てはまらずともエラーは出ますが、とにかく分析対象とするログファイルの数が多いほどエラーが出やすいということです。
過去のエントリから画像を流用して流れを確認します。
ポリシーを生成したい IAM ユーザーもしくはロールの画面から「ポリシーの生成」を押下します。
ポリシーの生成時にいくつかの条件を指定できます。
青枠で囲っているところが先ほど述べたログファイル数に関係するところです。
上記の条件で生成を実行すると、わたしの環境ではエラーが発生しました。
「失敗」という文字にカーソルを合わせるとエラーメッセージが表示されます。
CloudTrail log files processed per policy generation limit exceeded. Please fix before trying again.
分析対象の期間を最大の 90 日間、対象リージョンをすべてにしてポリシーの生成を試みると、くだんのエラーが発生するという状況です。
Access Analyzer のクォータを確認しよう
エラーメッセージには limit という文字が含まれていますので、クォータを確認してみましょう。以下から確認できます。
AWS CloudTrail log files processed per policy generations（ポリシーの生成ごとに処理される CloudTrail ログファイルの数）のクォータが 100,000 であり、上限緩和ができないことが読み取れます。
（日本語に切り替えるとgenerationsが「世代」と訳されるのがちょっと面白かったりしますね。）
ともかく、この 100,000 という数字を超過してしまっていることが原因のようです。
CloudTrail ログファイルの数をカウントしてみよう
90 日分で ログファイル 10 万個……、自分の環境でそれくらいあるような気もするし、無いような気もします。
というわけで実際に確認してみます。
ポリシー生成時の分析に指定した CloudTrail 証跡は以下の通りです。
マルチリージョンの証跡が有効で、以下のプレフィックスでログ出力を行うよう設定されています。
S3バケット名/AWSLogs/アカウント番号
そして、個々のログファイルは以下キーを持ちます。
S3バケット名/AWSLogs/アカウント番号/CloudTrail/リージョン/20YY/MM/DD/ログファイル名
マルチリージョン証跡を有効にしているので、各リージョンのプレフィックスが作成されています。わたしの環境では 17 リージョン分です。
% aws s3 ls cm-members-012345678910/AWSLogs/012345678910/CloudTrail/
PRE ap-northeast-1/
PRE ap-northeast-2/
PRE ap-northeast-3/
PRE ap-south-1/
PRE ap-southeast-1/
PRE ap-southeast-2/
PRE ca-central-1/
PRE eu-central-1/
PRE eu-north-1/
PRE eu-west-1/
PRE eu-west-2/
PRE eu-west-3/
PRE sa-east-1/
PRE us-east-1/
PRE us-east-2/
PRE us-west-1/
PRE us-west-2/
S3 バケット上のオブジェクト数をカウントしてみよう
aws s3 lsコマンドではいくつかオプションを使用でき、そのうち以下を組み合わせることで特定のプレフィックスを持つオブジェクト数を確認できます。
--recursive：再帰的にオブジェクトをリストする--summarize：オブジェクト数、トータルサイズのサマリを表示する--human-readable：ファイルサイズを人間が読みやすいフォーマットで表示する
ls — AWS CLI 2.2.38 Command Reference
そのまま叩くと当然オブジェクトの一覧が（大量に）出力されるわけですが、今回必要なのはサマリの数字だけです。一度テンポラリなファイルに書き込んでから末尾だけ表示することにします。
aws s3 ls S3バケット名＋プレフィックス \ --recursive --summarize --human-readable\ > /tmp/hoge.txt && tail -n 2 /tmp/hoge.txt
メインで使用している東京リージョンのひと月あたりのログファイル数を確認してみます。
% aws s3 ls cm-members-012345678910/AWSLogs/012345678910/CloudTrail/ap-northeast-1/2021/06/ --recursive --summarize --human-readable > /tmp/hoge.txt && tail -n 2 /tmp/hoge.txt Total Objects: 17955 Total Size: 38.7 MiB % aws s3 ls cm-members-012345678910/AWSLogs/012345678910/CloudTrail/ap-northeast-1/2021/07/ --recursive --summarize --human-readable > /tmp/hoge.txt && tail -n 2 /tmp/hoge.txt Total Objects: 17001 Total Size: 38.0 MiB % aws s3 ls cm-members-012345678910/AWSLogs/012345678910/CloudTrail/ap-northeast-1/2021/08/ --recursive --summarize --human-readable > /tmp/hoge.txt && tail -n 2 /tmp/hoge.txt Total Objects: 13320 Total Size: 30.8 MiB
バラつきはありますが、大体 16,000 個のオブジェクトが生成されているようです。
続いて、普段全く使用していないリージョンでも確認してみます。
% aws s3 ls cm-members-012345678910/AWSLogs/012345678910/CloudTrail/sa-east-1/2021/06/ --recursive --summarize --human-readable > /tmp/hoge.txt && tail -n 2 /tmp/hoge.txt Total Objects: 2264 Total Size: 3.4 MiB % aws s3 ls cm-members-012345678910/AWSLogs/012345678910/CloudTrail/sa-east-1/2021/07/ --recursive --summarize --human-readable > /tmp/hoge.txt && tail -n 2 /tmp/hoge.txt Total Objects: 2570 Total Size: 3.7 MiB % aws s3 ls cm-members-012345678910/AWSLogs/012345678910/CloudTrail/sa-east-1/2021/08/ --recursive --summarize --human-readable > /tmp/hoge.txt && tail -n 2 /tmp/hoge.txt Total Objects: 2255 Total Size: 3.6 MiB
サンパウロリージョンはコンソールで選択したことすらほぼありませんが、それでもひと月あたり 2,300 個程度オブジェクトが生成されています。
抽出していくつか確認すると、AWS Config や TrustedAdvisor によるリソースの参照が記録されていました。リソースを作成したりユーザーが操作したりしていなくても、 CloudTrial による記録は一定数発生しているということですね。
東京リージョン以外はほとんど触っていないのですが、サンパウロ以外のリージョンでも同程度のオブジェクト数がありました。
ざっくりの数で計算すると以下となります。
- メイン使用の東京リージョン：16,000
- 他の 16 リージョン：2,300 * 16 = 36,800
- 上記合計：52,800
ひと月分でもこの数なので、90 日分とすればクォータの 100,000 個は軽く超過してしまっていますね。
あくまでこれはわたしの環境での数字ですが、そこまでバリバリに使用しているわけでもないので、同等以上の数字になることは珍しくないと思っています。
ポリシー生成時には必要なリージョンだけを選択しよう
CloudTrail log files processed per policy generation limit exceeded. Please fix before trying again.というメッセージが出た時にどうしたらいいか、というエントリでした。
普段利用していないリージョンであればあえて分析対象とする意味合いは無いと思いますので、ポリシー生成時の対象からは適宜 取捨選択するようにしましょう。複数選択したい場合は、分析対象期間を短めにしてバランスを取ってみてください。
改めて調べて、CloudTrail のログファイルって意外とかさむもんなんだなという気づきを得ました。同じエラーに見舞われた方の参考になっていれば幸いです。
以上、エラーメッセージを見かけたので愚直にそのままコピペして検索したけどちょうどいい情報が見つからなかったのでじゃあ自分が書くかと思って書いちゃうおじさんこと、 チバユキ (@batchicchi) がお送りしました。
![[オフライン世界最速？AWS re:Inforce 2024 re:Cap セミナー] 『IAM Access Analyzer のアップデートを語ります』というタイトルで登壇しました。#AWSreInforce](https://devio2023-media.developers.io/wp-content/uploads/2024/06/240617_AWS_reInforce-2024_reCap-1.png)
